A patient in a hospital or in a department, for example in radiology, is treated in accordance with explicit or implicit rules which determine the “workflow”. To be able to support these workflows effectively using IT technologies, “workflow management systems” are being used to an increasing extent.
This requires the rules of the workflow to be modeled explicitly in a computer-interpretable form, for example by process models or by event-triggered rules.
Workflows controlled by humans normally do not have any prior modeling according to fixed criteria, however, but rather adapt flexibly to the situation to a certain extent. Thus, in a stressful or emergency situation, less time will remain for procuring old information or for compiling exemplary cases for teaching than in a normal routine mode. The network utilization level or the memory's filling level may also limit the volume of preloaded images.
The processing of a given task likewise follows more of a continuous sequence than a “strict progression”, and hence, depending on utilization level, work may actually be started even when all prerequisites have not yet been satisfied.
In workflow management systems known today, only discrete instructions and states and, derived from these, only discrete logic relations or rules are processed.
FIGS. 1 and 2 are used to describe an example of such a classical workflow management system. FIG. 1 shows a discrete process description for a process including a plurality of activities. Once the first activity 1, shown symbolically, is complete, the second activity 2 is started. Only when this second activity 2 is complete is the activity 3 started. This can also be shown more precisely with reference to the discrete flow shown in FIG. 2. A “workflow engine” 4 starts the first activity 1 in a first step a. Once the first activity 1 with its task has finished, it reports this to the workflow engine 4 in a step b. The workflow engine 4 then initiates the second activity 2 in a step c. Once the second activity 2 is complete, it reports this to the workflow engine 4 in turn in a step d, whereupon the third activity 3 is started on the basis of a step e.
Such a restriction to discrete variables therefore results in the following problems:    1. If the degree of discretization is too coarse, hard switching occurs between “fully or not at all” situations.    2. If, on the other hand, the degree of discretization if fine, then an extremely large number of cases need to be modeled explicitly by rules.